ci(renovate): block major indirect Go dep bumps#978
Merged
cpcloud merged 3 commits intomicasa-dev:mainfrom Apr 23, 2026
Merged
Conversation
…ooks PR micasa-dev#977 (the first batched go-indirect run under the new config) surfaced two remaining gaps: 1. Renovate kept attempting major-version bumps on indirect deps (openai-go v1 -> v3, modernc.org/libc v1 -> v2). A new major is a different Go module path, and nothing in the repo imports the new path, so `go mod tidy` strips the added lines on every workflow run. The PR is a guaranteed no-op that never reconciles with main. Disable major update-types for the indirect rule so Renovate stops opening them. 2. When `go mod tidy` does reshape go.sum without altering vendor contents (exactly the scenario above), the Commit and push step trips two pre-commit hooks that fire as false positives here: vendor-hash-check ("go.sum changed but nix/package.nix did not") and go-mod-tidy ("tidy would modify files" -- it already did, we are about to stage the result). Scope SKIP to these two hook IDs on that one step; all other hooks still run.
cpcloud
added
ci
The Tidy go modules step upstream already runs `go mod tidy`, so by the time the Commit and push step runs the tree is tidy and the go-mod-tidy hook is a pass-through no-op. Leaving it in SKIP was defending against a scenario that cannot occur on this path. vendor-hash-check is still skipped for the reason documented on the env comment.
Once indirect majors are blocked at the Renovate layer, every remaining Renovate PR that reaches this workflow bumps a module in place. go.sum changes and vendor content changes together, so the computed vendorHash moves with go.sum and nix/package.nix is always staged with a real diff. vendor-hash-check then has both files staged and exits 0 on its own. Suppressing it was papering over the symptom of the scenario that rule was added to eliminate. If the hook ever fires again from inside this workflow, that is a real invariant break worth investigating, not something to silence.
cpcloud
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #976. PR #977 showed that batching indirects (done in #976) does not by itself prevent a class of doomed PRs:
github.com/openai/openai-gov1 -> v3 andmodernc.org/libcv1 -> v2 were both proposed, and both new majors are different Go module paths that nothing in this repo imports.go mod why github.com/openai/openai-go/v3returns(main module does not need package ...).go mod tidystrips the added lines on every run, so the PR can never reconcile with main. DisablingmatchUpdateTypes: ["major"]forindirectdeps undergomodstops Renovate from opening them.With this rule in place, every remaining indirect PR that reaches the vendor-hash workflow bumps a module in place: go.sum changes and vendor content changes together, vendorHash moves with go.sum,
nix/package.nixis always staged with a real diff, andvendor-hash-checkpasses on its own. Thego-mod-tidyhook already passes because the upstreamTidy go modulesstep tidied. No workflow-side skips are needed. If either hook fires from inside this workflow after this merges, that is a real invariant break worth investigating -- not something to silence.Changes
renovate.json-- new rule disablingmatchUpdateTypes: ["major"]onindirectgomoddeps.Reproduction
Follow-up
Close #977 -- its branch carries the stuck state and Renovate will skip that update-type under the new rule.